1. Field
The present disclosure relates to the authenticating a client against a pool of servers utilizing a secure authentication protocol, and, more specifically, to the authenticating a client against a pool of servers providing a common service, utilizing the Kerberos secure authentication protocol.
2. Background Information
Kerberos is a trusted third-party authentication protocol designed for client/server interactions. J. Kohl and B. Neuman, “The Kerberos network authentication service (version 5),” RFC-1510, 1993. Hereafter, a service that is substantially in compliance with the above Kerberos specification, its derivatives, or antecedents is simply referred to as “Kerberos.” This includes imperfect or corrupted implementations.
A Kerberos service allows a person or client to access different machines on a network. Kerberos shares a different secret key with every entity on the network and knowledge of that secret key is considered proof of identity.
An example of a Kerberos session is illustrated in FIG. 1. A client 100 may wish to access a network service running on network server 120. In order to do so, it must verify that it has the proper credentials to access the service utilizing the Kerberos Key Distribution Center (KDC) 110.
Arrow 130 illustrates that in this example, when logging onto the network, the client may request a Ticket-Granting-Ticket (TGT) from the Authentication Service (AS) 113. The client may do this by answering a challenge issued by the AS using a password. Of course, other techniques are often used and this is merely an illustrative example. Once the AS verifies that the client is a valid entity on the domain, arrow 135 illustrates that a Ticket-Granting-Ticket may be issued. This TGT is typically cached on the local machine and used to request network service sessions throughout the network.
The Ticket-Granting-Ticket usually includes two parts: a main portion of the TGT which is encrypted with a key that only the TGS 117 can decrypt, and a session key encrypted with the client's secret key. This session key is used to handle future communications with the KDC. Because the client cannot read the main portion of the TGT contents, it must blindly present the ticket to the Ticket Granting Service 117 for service tickets. In some embodiments, the TGT also includes time-to-live parameters, authorization data, or other data.
When the client 100 wishes to access a Network Service 120, the client presents the Ticket-Granting-Ticket to the Ticket Granting Service (TGS) 117 and requests a Service Ticket, as illustrated by arrow 140. The TGS receives the TGT and decrypts it using the TGS's secret key. The TGS determines which server provides the service the client is requesting a ticket for. The TGS then encrypts a session key with that server's secret key. This encrypted session key is incorporated into the Session Ticket. Arrow 145 illustrates that the TGS may respond to a valid request by returning a valid Service Ticket to the client.
Arrow 150 illustrates that this Service ticket may be presented to network server 120 by client 100. The Network server may then decrypt the session key using the server's secret key. Arrow 155 illustrates that the client-server session may then be established. During each of the client-KDC and client-server transactions the various tickets may have been also encrypted with the client's secret key, allowing the KDC and client to verify that the transaction was not intercepted nor involved a spoofed client or KDC.
This is merely an illustrative example of a Kerberos transaction. However, it does illustrate that the Kerberos protocol assumes that one, and only one, server provides each service. Therefore, if a service is to utilize a Kerberos protocol, it must be tied to a single server. This prevents the use of a server pool and the ability for a network to perform load balancing, among other tasks. Some techniques avoid this problem by sharing a single password among multiple servers. This technique, however, increases the manageability of the servers, for example, all server passwords must by synchronized, and decreases the security of the server pool, for example, compromising one server eases the compromising of the rest of the server pool.